Repository navigation
feat(agent-vault): accept SOCKS5 over TLS on the proxy - #471
saifsmailbox98 wants to merge 4 commits into
Conversation
|
💬 Discussion in Slack: #pr-review-cli-471-feat-agent-vault-accept-socks5-over-tls-on-the-proxy Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel. |
 [High impact] The PR adds a network-facing entry point into Agent Vault’s credential-brokering path. The required event metadata loop must be added before merging; no new behavior defect was found. Findings
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Beyond the inline findings, I also checked whether the SOCKS5 private-destination guard in packages/agentvault/dial_guard.go could be bypassed. The upstream transport sets Proxy: nil, so the net.Dialer.Control hook sees the real resolved destination, not an intermediate proxy. Zone stripping and Unmap() stop IPv4-mapped and zoned IPv6 forms from slipping past the ranges.
Extended reasoning...
The change adds an internet-facing SOCKS5-over-TLS listener whose login is the session token, a dial-time block on private destinations, and new CLI flags, about 1.8k lines across packages/agentvault and packages/cmd. The dial guard is the main defense against SSRF on this listener, so I checked that no environment proxy sits between it and the real destination, and none does.
Findings marked 🟡 are optional suggestions and need no follow-up push.
Description 📣
Adds an opt-in SOCKS5 door to
infisical agent-vault proxy, so sandbox providers that tunnel a sandbox's traffic from outside the sandbox (E2B's bring your own proxy) can use Agent Vault. The session token goes in the SOCKS5 password, set on E2B's side, so it never enters the sandbox and the agent sets no proxy env vars.SOCKS5 door
--socks5-portturns it on (off by default), always over TLS, listens on all interfaces--socks5-tls-name: the proxy mints the port's certificate from its own CA and renews it. Or--socks5-tls-cert/--socks5-tls-keyfor your own (read once at start, expired cert refused)01 01). Passwords that aren't shaped likeagv_...are refused without asking Infisical0x07. After the reply the connection takes the same path asCONNECT(handleConnect's peek + MITM block moved intoserveIntercepted), so policy, injection, session logs and the mid-tunnel 403 are unchangedrecover; accept loop backs off on temporary errors like net/httpdoor=socks5, login refusals log the remote address and never the usernamePrivate destinations
On the SOCKS5 door only, under the any-host policy, a host no bundle service names can't resolve to a private, loopback, link-local or similar address (cloud metadata, the proxy's own network). It's checked at dial time on the resolved IP (
net.Dialer.Control), through a separate transport so it never reuses a connection the unchecked one opened. Same ranges as the backend'sipRange.ts, with zones stripped and IPv4-in-IPv6 unwrapped.--socks5-allow-private-destinationsturns it off. The HTTP door is unchanged.Other
--listen-hostto bind the HTTP port to one interface (host only, the port stays--port)INFISICAL_AGENT_VAULT_*env var, telemetry getssocks5,socks5OwnCert,socks5AllowPrivate,customListenHostpackages/cmd(they never ran before)Companion PR (CA download API, UI and the E2B guide): Infisical/infisical#9035
Type ✨
Tests 🛠️
# Here's some code block to paste some code snippets